【レポート】ChaosConf 18′ 19′ recap – ChaosConf2019 recap-
オペレーション部 江口です。
11/11に、Chaos Engineeringについてのカンファレンス「ChaosConf」のrecapを行うイベント、「ChaosConf2019 recap」がAWS Loft東京で行われました。
行われた3セッションのうち、2セッションはすでに同僚によってレポートのブログが上げられています。
【レポート】Chaos Engineering が合うもの/合わないもの – ChaosConf2019 recap –
私も参加してきましたので、Cygames 和田氏の講演、「ChaosConf 18' 19' recap」についてレポートさせていただきます。
スピーカー
和田 明久氏 株式会社Cygames Infrastructure Division / Software Engineer
アジェンダ
- ChaosConf 18', 19' (ChaosConf18'と19'で何が違ったかの比較)
- Chaos Journey along with Chaos Conf (Chaos Engineeringの実践を5つのポイントで整理)
- Motivation
- Negotiation
- Observability
- Experiment
- Post-mortem
- Prediction: Next Chaos Topics(次にトピックとなるであろう話題の予想)
講演内容
1. ChaosConf 18', 19' (ChaosConf18'と19'で何が違ったかの比較)
- 会場:2018年は収容人数400人の会場。2019年は収容人数600人の会場に拡大
- セッションリスト:2018年はセッションのみで、セッション数は10だった。2019年は、セッション(9つ)に加えてブートキャンプ1つ、LT4つと多彩に。
- ブートキャンプについてはCygamesテックブログで記事を公開 https://tech.cygames.co.jp/archives/3323/
- セッションのテーマ - 「Why」と「How」: 2018年のセッションは「Why」、すなわちなぜChaos Engineeringを行うかについてのセッションが多かったが、2019年のセッションは「How」、すなわちどうやってChaos Engineeringを行うかにフォーカスしたセッションが多かった
- 登壇者の業界の変遷 : 2018年のセッションと2019年のセッションの登壇者の業界の比較。2019年はリテール業界の登壇者が増えたほか、メディア関係者の登壇もありバラエティが増えた
セッションの違いの例として、2018年と2019年のセッションがいくつか紹介されました。
2018年
- How to Convince Your Boss to Say "Yes!" to Chaos Engineering
- 上司からChaos Engineeringの承認を取る方法について3STEPで紹介するセッション
- いくつかのアプローチ(脅してみるなど)を試した結果、「合理的に説得する方法」がうまくいったとのこと
- Staying Alive: Patterns for Failure Management from the Bottom of the Ocean
- ダイビングにおけるリスク管理の話
2019年
- THINK BIG: CHAOS TESTING A MONOLITH
- モノリシックな環境に置いてCHAOS TESTINGを行なった事例の紹介
- モノリシックなアプリケーションはマイクロサービスに比べて失敗注入がしづらいが、LBのFailoverやDBをread onlyにしてみるなど、周辺の環境に失敗を注入してテストを行うだけでも知見が得られた
- INCIDENT REPRO & PLAYBOOK VALIDATION WITH CHAOS ENGINEERING
- 2017年に発生したAWS S3の障害の再現実験を紹介
こぼれ話としてチケット料金が他のイベントに比べて安い、という話もありました。re:inventが$1800近いのに対して、ChaosConfは#399!ということで、参加したい方はこれをネタにして上司を説得すると良いでしょう。
2. Chaos Journey along with Chaos Conf (Chaos Engineeringの実践を5つのポイントで整理)
Chaos Enginneringの実践の5つのポイントについて、実際の講演で話された内容を引用しつつ紹介されました。
Motivation : なんのためにやるのか、なぜやるのか
- 複雑な分散アーキテクチャの信頼を向上させるため
- システムは人間が作る、人間は間違いを犯しやすい。すなわちシステムは壊れやすい
- なのでChaos Engineeringを実践して備える
Negotiation : 周りをどう巻き込むか
- どうやって上司をYESと言わせるか?
- Step1: なじみを持ってもらう
- Step2: どのようなプレイヤーがいるか把握する
- Step3: プレイヤー毎のストーリーを作る
- 合理的な説得がもっともROIが高い(=効率が良い)
- マネージャーにどう提案するか?
- なぜ「動いているのに壊すのか?」という点については、「障害をあらかじめ検知・修正できる方が事後に発覚するよりも良い」 というのが回答
- 専門知識がなくてもChaos Engineeringツールがすでに多くあり、壊すことに関しては簡単に行える
Observability: 可観測性
- Observabilityが無いChaos engineeringはただのchaos
- 観測が行えるように準備を整える
- ログ、トレース、メトリクス、レポート、アラート
Experiment : 実験
- 実験の流れ
- Steady state(正常な状態の定義)を決める
- 仮説を立てる
- 実験を実際に行う
- 検証
- 修正
- 上記を繰り返す
- 実験は以下のような目的で行うことができる(=実験の対象)
- オンコール対応の訓練
- ツールと手順書の有効性を検証
- インシデントの再現確認とPlaybookの検証
- 組織の検証
Post-mortem : 実験の振り返り
- 実験が終わったら振り返りを行う
- ChaosConfのBootCampでは簡単な振り返りシートに記入する形で行なった
- Focusing on problems, not indivisuals(問題にフォーカスし、個人に責任を押し付けない)
- 実験前にPre-mortem(事前の意識合わせ?)を行うと良い
3. Prediction: Next Chaos Topics(次にトピックとなるであろう話題の予想)
以下がトピックとして挙げられました。
- Resilience Driven Development(RDD)
- Chaos Driven Development(CDD)
- ServerlessへのChaos Engineeringへの適用事例
- APplication LayerでのChaos Engineering
- マネジメント領域への応用事例
- MLと融合したオートメーション
感想
Chaos EngineeringといえばNetflixのChaos Monkey・・・程度の理解で止まっていた私としては、ここ最近のChaos Engineeringのトレンドの推移がわかって勉強になりました。
オペレーション部では8月に発生したAWS障害の反省も踏まえて、社内でGameDayの実践をしたい、といった議論をちょうどしていたところだったので、後半のChaos Engineeringの実践方法についての紹介は非常にタイミングが良かったです。私はサービスの品質管理の担当ですので、ぜひこのセッションで得た知見をもとに、GameDayに限らず社内でのChaos Engineeringの実践を検討してみたいと思います。
以上、ChaosConf2019 recapのセッションChaosConf 18' 19' recap」の紹介でした。